NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/189

Internet Message Format | 1996-08-05 | 3.6 KB

Path: mujibur.inmind.com!usenet
From: [e-mail]
Newsgroups: comp.lang.c++
Subject: Re: Hungarian notation
Date: 3 Jan 1996 02:36:14 GMT
Organization: In Mind, Inc.
Message-ID: <4ccq2u$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4c44dh$[e-mail]> <4c477m$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: finneyman.inmind.com
X-Newsreader: IBM NewsReader/2 v1.2

In <4c477m$[e-mail]>, [e-mail] (Warren Young) writes:
>[e-mail] wrote:

>Sure the semantics change.  Try passing the latter to printf() and see
>how broken the program gets.  Or strlen(), or strtou()...  Granted,
>you're likely to be changing the string manipulation functions at the
>same time, but this is one place where HN becomes useful: helping you
>find the places where you missed a function call that needs changing.

In all of the cases, except printf(), the function prototypes (everyone
uses those, right?) will catch any type change which is incorrect.  And
printf() is kinda obsolete.  If you are dealing with wide character types
you are almost certainly not going to be using printf().  But, even if you
were, a global grep for printf / "insufficientStorage" would catch all of
those combinations.  So Hungarian notation doesn't buy you much here.

And surely, there are no functions requiring ellipses in the prototype
in anything written recently?  Certainly not in any code my company
writes nor in any code I  have written in the past two decades.  Type
safefty is available in the language.  Those who don't use it get what
they deserve.

>>The use of upper case names to distinguish #define names is one
>>of the worst pseudo-standards that have been fostered upon the
>>programming community.  Right up there with Hungarian notation.
>
>It's very useful with macros, because it tells the reader, "Hey!  The
>arguments to this macro aren't type-safe and there may be
>side-effects!"  With C++, though, I have a solution that both of us
>might find acceptable: dump #defines for consts and inline functions.

Only sometimes.  I personally use const data elements and inline
functions whereever possible.  But they simply do not replace
all uses of #define.  And if you have very many global constants
the use of const data elements can add a LOT of space to the
compiled program.  Not always acceptable.  With #defines and
constant folding in the compiler/linker that is less of a problem.

And macro functions are still useful -- although much less frequently
than in the past.  I have used them to "map" a common function to
different operating systems.  Here, even the inline template function
doesn't work well.  Further, the code is reduced since the alternate
operating system code goes away at compile time.  An example of
this is the _beginthread() function under OS/2 and NT.  They are
"almost" the same.

Another example was the use of printf() in some
C code.  It turns out that the Microsoft compiler didn't support printf()
in the library for some types of programs, but you could call a system
wprintf() to do the same thing (with restricted types, but that was
acceptable for the project).  The use of #define allowed a direct map
for the appropriate operating system.  I don't recommend the use of
C, printf() or any Microsoft operating system but those were the
restrictions I had to live with for that project (but that same project
had to be portable to other systems).


Michael Lee Finney